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Abstract 

The advancements in the Internet and Web 
technologies have fueled a growing interest in developing 
a web-based distributed computing environment . We have 
designed and developed Arcade, a web -based 

environment for designing, executing, monitoring, and 
controlling distributed heterogeneous applications, which 
is easy to use and access, portable, and provides support 
through all phases of the application development and 
execution. A major focus of the environment is the 
ipecification of heterogeneous, multidisciplinary 
applications . '? this paper we focus on the visual and 
script-based specification interface of Arcade . The 
web/browser-based visual interface is designed to be 
intuitive to use and can also be used for visual monitoring 
during execution. The script specification is based on 
XML to (a) make it portable across different frameworks, 
and (b) make the development of our tools easier by using 
the existing freely available XML parsers and editors. 
There is a one-to-one correspondence between the visual 
and script-based interfaces allowing users to go back and 
forth between the two. To support this we have developed 
translators that translate a script-based specification to a 
visual-based specification , and vice-versa. These 
translators are integrated with our tools and are 
transparent to users. 

1. Introduction 

The advancements in the Internet and Web 
technologies have fueled a growing interest in developing 
a web-based distributed computing environment. We have 
designed and developed Arcade [3], a web-based 
environment for designing, executing, monitoring, and 
controlling distributed heterogeneous applications. The 
focus of Arcade is to support simulations and 
computations that consist of multiple heterogeneous 
modules interacting with each other to solve an overall 
design problem. For example, Multidisciplinary Design 


Optimization (MDO) methods are being explored at 
NASA Langley Research Center (LaRC) for the design 
optimization of aerospace vehicles [12]. Typically the 
modules in such applications are developed in different 
disciplines and are optimized independently. The 
traditional path for integrating these modules, through the 
use of scripts, makes the process of specifying and 
optimizing the overall design of such applications a long 
and tedious process often taking several weeks. The 
slowness of this process is mainly due to the absence of a 
collaborative environment where (i) different modules 
and their interactions can be specified, and (ii) testing, 
monitoring, and steering of the overall design can be done 
by multiple users from different disciplines concurrently. 

The objective of Arcade is to design an environment, 
which is easy to use, easily accessible, portable, and 
provides support through all phases of the application 
development and execution. We implement various parts 
of the environment by leveraging off commodity 
technologies, such as the Web, Java, and Jini along with 
service layers such as Globus [5] being implemented by 
various research groups. These technologies are capable 
of seamlessly interconnecting disparate hardware 
platforms running different operating systems across 
diverse locations providing an ideal environment for 
distributed simulation of complex systems. The problem 
is that these technologies are relatively new and there is 
not enough experience with them in building such a 
framework for large-scale distributed applications. The 
major issues that need to be considered for building such 
an environment are: 

• Design of a protocol over HTTP to support 
communication between different components of 
the environment that addresses the MDO-like 
application requirement. 

• A visual tool to enable users to specify a MDO-like 
application. Also, related to this issue is the design 
of a visual language specification that has one-to- 
one correspondence with the visual representation. 

• Application Programming Interfaces (APIs) 
specification to allow different visualization and 


resource management tools to easily work with the 
proposed environment. 

• Collaboration support in the design, execution, and 
monitoring phases of a distributed heterogeneous 
application. 

• Multi-domain support to allow users from different 
domains to work together. 

The focuses of this paper are the visual- and script- 
based interfaces for the Arcade framework. To better 
understand the requirements on these interfaces, consider 
a use case scenario for developing and executing a 
distributed application. A team of designers 
collaboratively develops the application consisting of a 
hierarchical set of modules. That is, individual members 
are made responsible for specifying the submodules while 
the project leader is responsible for the overall integration 
of the application, i.e., connecting the outputs of one 
module to the inputs of another. For this purpose, 
members can use visual- or script-based specification. 
Note that the modules can range from simple sequential 
programs to data parallel programs capable of execution 
on a multiprocessor or a network of workstations, to more 
complex subsystems, which are defined hierarchically 
through the use of submodules. Once developed, the 
application is executed in a distributed environment using 
a heterogeneous network of workstations and 
multiprocessor machines. During the execution, team 
members sitting at their individual workstations 
simultaneously monitor the flow of progress of the 
application. That is, the team members can see the 
currently executing modules at any level of the hierarchy. 
They can also monitor the intermediate data between 
different modules using visualization tools to view large 
data sets. A team member responsible for a particular 
subsystem can change data values under the control of the 
subsystem in order to steer the computation in the right 
direction. The team member can also dynamically alter 
the control flow if necessary. For example, in a design 
cycle, the responsible team member may decide that a 
particular module is not affecting the optimization and 
may bypass the module by using old values in each cycle. 
Similarly, the team could replace a module with a plug- 
compatible module, for example, to use another 
algorithm. Once the execution is complete, team members 
again can examine the final results using the visualization 
tools. 

In this paper we describe the visual- and script-based 
specification interfaces of the Arcade system. The 
web/browser-based visual interface is designed to be 
intuitive to use. Once specified the same visual 
representation of the application can also be used for 
visual monitoring during execution. The script 
specification is based on XML. Using XML allows us to 
leverage off existing freely available XML parsers and 
editors to develop our tools. Also, such an XML-based 
script presents the potential of inter-framework 


portability. Thus, if a piece of the overall application 
needs to be executed by another framework, we could 
translate that portion of the XML specification into the 
framework specific representation. There is a one-to-one 
correspondence between the visual- and script- based 
interfaces allowing users to go back and forth between the 
two. Thus, some users will specify the application 
visually and then use the script representation to make 
changes. On the other hand, other users may be more 
comfortable writing the XML script using an offline 
editor and then using the visual representation for 
execution. To support this we have developed translators 
that translate a script-based specification to a visual-based 
specification, and vice-versa. These translators are 
integrated with our tools and are transparent to users. 

The rest of this paper is organized as follows. In 
Section 2, we present some of the related work. Section 3 
describes the overall architecture of the Arcade system. 
Section 4 focuses on the application specification 
prototype in Arcade and, finally, in Section 5 we conclude 
by summarizing the work that we have described in this 
paper. 

2. Related Work 

Several software systems have been developed that 
make distributed computing available to an application 
programmer. These can be distinguished into different 
categories. The first category of environments includes 
systems such as MPI [11], PVM [16], pPVM [10], and 
JAVADC [4]. All these environments support distributed 
computing in varying degrees of generality; however, 
either they are not web based or they lack collaborative 
features. Also, they are mostly suitable for running SPMD 
programs. 

The second category consists of environments that 
focus on large distributed heterogeneous codes, but are 
generally specific to a single application domain. 
Examples of such environments include FIDO [18], 
MIDAS [14], NetSolve [2], and Ninf [13]. However, both 
systems are either hardwired to a specific problem area or 
are too restrictive. The other major limitation is that they 
lack a collaborative environment, which would permit 
different members in a group to interact with the 
application at various stages of its design and execution. 

The third category of environments that includes IceT 
[6], Programmer's Playground [7], PRE [15], VDCE [17], 
HeNCE [8], and WebFlow [1], supports heterogeneous 
distributed applications in some form or other. For 
example, the Grid Enabled Console Component 
(GECCO) [9] is a graphical tool that has been built on top 
of Globus [5] to allow users to interactively specify and 
monitor the execution of a set of tasks with dependencies 
between them. GECCO enables the user to formulate job 
execution as a task graph. 



The front-end for most of these systems is generally 
some variation of large-grained data flow graphs with 
computational modules being triggered when their inputs 
are available. In our experience, we have found that to 
easily express heterogeneous applications requires more 
control structure than provided by such data flow-based 
systems. For example, in a multidisciplinary optimization 
code, the optimization cycle would have to be embedded 
within a module in a system that only supports data flow 
rather than being explicit at the outer level. Also, these 
systems mainly concentrate on different aspects of the 
infrastructure required for managing the execution and 
interaction of the modules making up the application 
whereas the goal of the project described here is to build 
an integrated framework for all phases of the design and 
execution of distributed heterogeneous applications. 
However, such collaborative systems do not provide any 
support for the management and steering of the execution 
of distributed applications. 

3. Overview of Arcade 

Arcade is a web-based integrated metacomputing 
environment that is being built to provide support for a 
team of discipline experts to collaboratively design, 
execute, and monitor multidisciplinary applications on a 
distributed heterogeneous network of workstations and 
parallel machines. This framework is suitable for 


applications, which in general consist of multiple 
heterogeneous modules interacting with each other to 
solve the overall design problem, such as the 
multidisciplinary design optimization of an aircraft. As 
shown in Figure 1, Arcade is based on a three-tier 
architecture. The first tier is a web-based, lightweight 
client, which provides the user interface to the whole 
system. It consists of applets, which allow users to design 
an application, monitor and allocate resources, and 
execute, monitor and steer the application in a 
collaborative manner. It also has interfaces, which allow 
the system administrator to manage the system including 
resource registration and user management and 
authentication. Most of the logic of the system is 
contained in the Java-based middle tier. Among other 
modules, the middle tier consists of the User Interface 
Manager , which provides logic to process the user input 
and coordinate between the other components; the 
Execution Manager , which manages the overall execution 
of the application; the Data Manager , which manages the 
shared data; the Resource Manager , which manages the 
distributed heterogeneous resources of the system; and the 
Security Manager , which controls the access of the 
system. The third tier consists of the distributed resources 
that are used to actually execute the user modules and 
application codes. A lightweight controller executes on 
each resource providing a gateway to the resource. 



Figure 1. The ARCADE System Architecture 
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Figure 2: Representation of Project and associated objects using UML 


4. Application Specification 

In our framework, a distributed application consists 
of a collection of heterogeneous modules (application 
codes from different disciplines). We are targeting 
applications where these modules are very coarse grained. 
A typical distributed application requires these modules to 
be executed in some order and possibly on different 
machines. For certain problems, a set of modules may 
need to be executed iteratively, for example, until a 
desired optimization criterion is reached. 

In Arcade, each application is internally represented 
as a Java Project object. Figure 2 provides the description 
of the Project and associated objects in UML. Here 
aggregation means the contains relationship. 
Generalization means the is-a relationship. The number 
on the arrow specifies the number of instances contained. 
For example, * on the aggregation between Project and 
Module means a Project can contain 0 to arbitrarily many 
Modules. The generalization between Module and 
NormalModule implies that NormalModule is a kind of 
Module . 

The Project object consists of a vector of Module 
objects. This is the central object in our framework. All 
the information related to the application, both static and 
dynamic, is stored within this object. The Project object is 
a complex object that is shared by all the processes of the 
middle tier, (cf. Figure 1) and supports methods that are 
used by these processes. 


To be able to support a wide variety of distributed 
applications, we support different types of modules. All 
these modules have a common set of properties and, 
hence, are derived from a general Module object. Some 
common attributes of the Module object are: 

• Module Name 

• Module Directory 

• Input/Output Names. 

The following types of modules derive from the general 
Module: 

• Normal Module : This is the basic module in our 
framework and is used to represent the executable 
parts in the applications. A Nonnal Module is 
identified by its executable code, command line, 
arguments, resource requirements, and input/output 
file requirements. 

• Loop Modules'. These modules allow a set of 
“internaF' modules to be iteratively executed. 
There are two kinds of looping modules: For 
Module for a predetermined number of iterations 
and the While Module , where the iteration 
condition is tested at the beginning of the loop. 
These modules have a Project object, which 
represents the set of internal modules. 

• If Module: This module provides a mechanism for 
testing the value of a condition. The truth-value of 
the condition determines whether the modules in 
the then-block or the else-block (if present) will be 
executed. 







• Hierarchical Module : An abstract Module 

representing a subgraph, i.e., a recursively defined 
collection of modules. 

In the current prototype there are two ways to specify 
distributed applications: visual based and XML-script. 
We describe these two approaches in the next two 
subsections. The First subsection talks about the visual 
specification of the project and how a user can visually 
specify an application. The second subsection talks about 
how an application can be represented using the script- 
based XML format. 

4.1. Visual Specification 

The visual specification applet allows a user to 
graphically specify a heterogeneous application. The 
objective is to support a visual specification, which is 
intuitive to build, can be used for visual monitoring, and 
works with the Web. 


We have implemented a Java applet, as shown in 
Figure 2, that provides a visual specification interface and 
addresses some of these issues. In the background of the 
figure, we can see the Application Editor window where 
the user can graphically specify the modules that 
comprise the application and their intercommunications. 
When a module is specified, a separate pop-up window 
appears allowing the user to specify the properties of the 
module. In the bottom left of the figure, we have the 
module information window for the Normal Module Mi. 

The application can be seen as a graph where a node 
represents a module and the arcs represent data flow. It is 
easy to see how a data flow-based application can be 
modeled using such a system. When the output port of a 
module is connected to the input port of another module, 
another pop-up window appears allowing the user to 
specify the interconnection. In the upper right of the 
figure, we have a dependency information window where 
the user is specifying a data flow between Ml and M2. 



Figure 3. Snapshots of the visual specification in Arcade 
















It becomes a little trickier to accommodate control 
structures such as conditionals and iterations, in particular 
when we want to use the visual specification for 
monitoring too. We accommodate If Modules and Loop 
Modules by restricting their bodies to be Hierarchical 
Modules , which are specified through a separate window. 
Thus, the modules labeled Then-block and Else-block 
represent Hierarchical Modules abstracting the then and 
else part of the If Module construct, respectively. 
Similarly, the module Body , represents the loop body of 
the for loop. Restricting the bodies of control structures to 
Hierarchical Modules eases the task of specification and 
allows the application to be visually represented. 
However, it does not provide an integrated view of the 
whole application in a single window, i.e., the body of a 
control structure is always shown in a separate window. 
In the bottom right of Figure 3, we have the module 
information window for the Loop Module Loopl along 
with its body. 

The visual representation of an application described 
above can also be used to monitor an application during 
execution. A monitoring applet uses a pre-deter mined 
color-scheme to indicate modules, which are pending, are 
currently executing, and have finished execution. 

4.2. XML-script Specification 

Arcade supports XML based specification of a 
heterogeneous application. The syntax of the script is 
simple and the DTD for XML specifications can be found 
at hUp://vvww. icase.edu/arcade/proiect.dtd . The XML- 
based project specification consists of two parts: 
specification of different types of modules used in the 
Project object, and the dependency graph between these 
modules. We now give sample XML specifications for 
the Project followed by different types of modules and 
the dependency graph . For simplicity, only important 
attributes are shown here. For detailed, functionally 
correct, and specifications please refer to the DTD. 

As explained earlier in this section, all the modules 
are bundled in a Project . A sample Project object looks 
like this in XML: 

<Project name=" Path Finder" owne^="ajakatda"> 

<XModule ...> "■) 

y n number of times. 

</XModule ...> 

<Graph> 

</Graph> 

</Project> 


Here, XModule can be one of Normal , For, While , or 
If modules described below. The Graph describes the 
dependency information about the modules that comprise 
the Project . The Project also has a name and an owner . 

As we described earlier, all the modules are inherited 
from a general Module object. A sample Module looks 
like this: 

<Module name="M1" directory="/home/ahmed/PathRnder " 

sfartx="260" starty="5 2" endx= m 260" endy=” 28" > 

<ModulelO type="\ nput" nama= B I OFileO" 
filename=* ini” extemahT editabie= H Y7> 

<ModulelO fype= ,, Output" name=10Filer 
filename ^" outl " extemahT editable^" Y7> 

</Module> 

Along with the basic information, Module also stores 
information about its input and output, and some 
graphical information required by the visual 
specifications. 

A Normal Module is the basic module in our 
framework. A sample XML specification of the Normal 
Module looks like this: 

<NormalModu!e dafaFa//?="/home/ahmed/PathFinder " 
comma nd Li ne= n -c $A $B H machineName= H tose a 
machineNameEditabfe=''la\se" execName =” Ml "> 

<Module name="M1" ...> 


</Modu!e> 

<ModuleParam name="A“ value=*907> 

<ModuleParam name="B" va!ue="100" /> 

</NormalModule> 

As one can notice along with the basic information like 
executable code, command line, argument, and resource 
requirements, it also stores some administrative 
information, like can a user edit the parameters, and some 
functional information such as machine name to execute 
the Normal Module. 

A For Module is used for representing the loops of 
fixed repetitions. A sample For Module looks like this in 
XML: 

<ForModule low = u 1* high = m 10*> 

<ModuIe name=''Loopr ...> 

</Module> 

<ProJect name= m Loopl " owner = "ajakatda"> 
<NormalModule ...> 

</NormaIModule> 

</Project> 

</ ForModule> 
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Figure 4: Storing and retrieving of the Project object in XML 


An If Module is used for representing the decision 
scenario. A sample If Module looks like this in XML: 

<ifModule cond/t/onPat/7=7home/PathFinder/lf/cond" > 
<Modu!e name=" IF" ...> 

</ModuIe> 

<Pro]ect name="then Project" owner = "zubair"> 


</Project> 

<Project name=" else Project" owner - U zubair"> 

</Project> 

</lfModule> 

The If Module also has a child called Module , as it is also 
a type of general Module . Notice that If Module may have 
two Projects in it. These are separated from each other by 
their order. The first one is always treated as a Then 
Project and the second one, if exists, is treated as an Else 
Project. 

The dependency is implemented using files or 
signals. Consider sample modules Ml and M2, where an 
input of M2 depends on an output of Ml, (cf. Figure 3). 
The Graph specification will look like this: 

<Graph> 

<Edge From=”M1" 7b=”M2"> 

<Deplnfo Output^ outr lnput= n out17> 

</Edge> 

</Graph> 


4,3 Storing and Retrieving of the Project object 

The user can design the project online using the 
visual tools provided, or he/she can write an XML script 
specification offline. We have to provide support for 
conversion between these two formats. 

Storing the Project Object: The ProjectSaver Class 
starts the process of saving the Project . Each Class, 
extending from Module class, implements a procedure to 
write itself to the file in XML format. So all the 
components write themselves recursively to the specified 
file (see Figure 4(a)). 

Retrieving the Project Object: The Project parser 
class implements the XML parser, which reads the XML 
file and generates a Project along with its visual 
information. It does so by generating an empty Project 
first and then adding individual Modules to it. As shown 
in Figure 4(b), the Project loader class calls this parser. 

5. Conclusion 

In this paper, we have described the application 
specification interfaces for Arcade, a web-based 
environment for distributed heterogeneous applications. 
We describe two interfaces: visual and script based. The 
visual interface has been designed to allow users to drag 
and drop modules providing the information required for 
each module. The dependencies between modules can 









also be specified graphically. The system also supports 
control dependencies using hierarchical modules to 
specify the bodies of loops and the then and else blocks of 
conditionals. Such an approach shows just the data 
dependencies at each level, hiding the control structure in 
the hierarchy. The visual representation is, thus, clean 
with no cluttering of control and data dependencies. 
However, this approach does not seem to provide an 
overall view of the application in a single window forcing 
users to look through multiple windows. We are currently 
experimenting with other views. 

The second interface is script based. We use an 
XML-based script for offline specification of the 
application. We can, thus, leverage off XML tools to 
build the interfaces. The use of XML also provides a 
more standard approach to specifying distributed 
applications that presents the opportunity of inter- 
framework portability of such specifications. We are 
currently exploring the translations required for such 
interoperability. 
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